
SCRUB User Interface is shown when it is opened in local mode. 


code with these tools can vary greatly. In 
each case, however, the tools produce re- 
sults that would be difficult to realize with 
human code inspections alone. There is 
little overlap in the results produced by 
the different analyzers, and each analyzer 
used generally increases the effectiveness 
of the overall effort. The SCRU B tool al- 
lows all reports to be accessed through a 
single, uniform interface (see figure) that 
facilitates browsing code and reports. Im- 
provements over existing software in- 
clude significant simplification, and lever- 
aging of a range of commercial, static 
source code analyzers in a single, uni- 
form framework. 

The tool runs as a small stand-alone 
application, avoiding the security prob- 
lems related to tools based on Web- 
browsers. A developer or reviewer, for in- 
stance, must have already obtained 
access rights to a code base before that 
code can be browsed and reviewed with 
the SCRU B tool. The tool cannot open 
any files or folders to which the user 
d oes n ot al ready h ave access. T h i s mean s 
that the tool does not need to enforce or 
administer any additional security poli- 
cies. The analysis results presented 
through the SCRUB tool's user interface 
are always computed off-line, given that, 
especially for larger projects, this com- 
putation can take longer than appropri- 
ate for interactive tool use. 

The recommended code review 
process that is supported by the SCRUB 
tool consists of three phases: Code Re- 
view, Developer Response, and Closeout 
Resolution. In the Code Review phase, all 
tool-based analysis reports are generated, 
and specific comments from expert code 
reviewers are entered into the SCRUB 


tool. In the second phase, Developer Re- 
sponse, the developer is asked to respond 
to each comment and tool-report that was 
produced, either agreeing or disagreeing 
to provide a fix that addresses the issue 
that was raised. In the third phase, Close- 
out Resolution, all disagreements are dis- 
cussed in a meeting of all parties involved, 
and a resolution is made for all disagree- 
ments. The first two phases generally take 


one week eac h , an d th e th i r d p h ase i s co n - 
eluded in a single closeout meeting. 

T his work was done by Gerard ]. H olzmann 
of Caltech for NASA's Jet Propulsion Lab- 
oratory. Further information is contained in a 
TSP (see page 1). 

T hissoftwareisavaiiablefor commercial li- 
censing. Please contact Daniel Broderick of 
the California Institute of Technology at 
danidb@caltech.edu. Refer to NPO -46817. 
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The M orbiter software numerically aver- 
ages an osculating orbit'sequationsof mo- 
tion (EOM) to arrive at the mean orbit's 
EO Ms, which are then numerically propa- 
gated to obtain the long-term orbital 
ephemerides. The long-term evolution 
characteristics, and stability, of an orbit are 
best characterized using a mean element 
propagation of the perturbed, two-body 
variational equations of motion. The aver- 
age process eliminates short period terms, 
leaving only secular and long period ef- 
fects. Doing this avoids the Fourier series 
expansions and truncations required by 
the traditional analytic methods. 


The numerical methods require no ana- 
lytic approximation, and the averaging the- 
ory and software implementation work at 
any solar system body. J PL's Monte mission 
analysis and navigation software was used 
as the underlying trajectory system (to the 
extent possible) for this innovation. 

Morbiter is a package of Python scripts 
that implement the algorithms, and uses 
M onte for basic astrodynamics constructs 
and functions such as trajectories, 
ephemerides, coordinate systems, astro- 
dynamics constants, and, in most cases, 
the perturbation acceleration methods. 
Python is an interpreted language that 


provides an ideal platform for rapid de- 
velopment of algorithms; however, there 
is a performance penalty for using 
Python script-based applications. An 
end-user, future version of Morbiter that 
is fully compiled will not suffer from this 
speed penalty; development of this ver- 
sion is planned to begin in late FY '10. 

T his work was don e by Todd A. Ely of Caltech 
for NASA's Jd Propulsion L aboratory. For more 
information , contact iaoffice@jpl.nasa.gov. 

T hissoftwareisavaiiable for commercial li- 
censing. Please contact Danid Broderick of 
the California Institute of Technology at 
danidb@caltech.edu. Refer to NPO-47212. 
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